TypeScript syntax in a .js Edge Function

let normalizedBody: string; is TypeScript syntax introduced into a plain .js file. The tsconfig.api.json does not include "allowJs": true, so tsc will skip this file entirely and the annotation goes unchecked. Vercel's esbuild bundler treats .js files as JavaScript by default — it does not apply the TypeScript loader — so this colon annotation will produce a parse error at bundle/deploy time.

The rest of the codebase uses .ts for TypeScript-annotated API files (e.g., api/mcp.ts, api/skills/fetch-agentskills.ts). Either:

• Remove the annotation and let the variable be inferred (let normalizedBody;), or
• Rename the file to telegram-feed.ts to match the other typed API files.

Fixed: removed the TypeScript annotation from the .js Edge Function. Changed let normalizedBody: string; to let normalizedBody; — Vercel's esbuild treats .js files as plain JavaScript and would reject the type annotation at bundle time.

Silent zone drop when normals exist but a zone is missing

When hasNormals is true, daysToFetch is set to 7. In fetchZone, if a zone is not found in the normals cache (!zoneNormal), the code falls back to the rolling baseline with baselineTemps = temps.slice(0, -7). With only 7 days fetched, this slice produces an empty array, hitting the if (baselineTemps.length < 7) return null; guard and silently dropping the zone.

Crucially, this null return does not increment failures — it is simply filtered by if (result != null) in the caller. So zones that lack a matching normal when hasNormals=true (e.g., newly-added climate zones that haven't been seeded yet) are silently excluded from anomalies without any counter increment. This could make it harder to diagnose why the anomaly count is lower than expected.

Consider incrementing failures (or at least emitting a console.log) when fetchZone returns null due to a missing normal in the partial-normals scenario, so that the gap is visible in logs.

Addressed: added a console.log in fetchZone() for the case where hasNormals=true but a zone has no matching normal AND insufficient fallback data (<7 baseline days). This makes silent drops visible in logs rather than filtering them out without trace.

multiplier absorbed inside log, reducing its effect

The new formula is Math.log1p(h.eventsPoliticalViolence * multiplier) * 12. Moving multiplier inside log1p substantially compresses its influence: the difference between multiplier=1 and multiplier=2 is now log(1 + 2x) − log(1 + x) rather than a straight doubling.

For example, with 46 events:

• multiplier=1: log1p(46) * 12 ≈ 46.2
• multiplier=2: log1p(92) * 12 ≈ 54.4 (+18% vs the old +100%)

If multiplier is meant to be a linear regional threat scale (as suggested by its use in acledScore), placing it outside the log would preserve that intent:

Fixed: moved multiplier outside the log so it preserves its linear regional threat scaling effect. Changed from Math.log1p(events * multiplier) * 12 to Math.log1p(events) * 12 * multiplier. This keeps multiplier as a linear amplifier rather than compressing it inside the logarithm.

Only allNormals.length === 0 throws; partial failures pass silently

The guard if (allNormals.length === 0) only aborts when the run produces zero results. The MIN_ZONES threshold (15) is enforced downstream in validate(), but the error message thrown here only fires at 0. If, say, 10 zones succeed but 12 fail, fetchAllZoneNormals returns the partial set, validate() rejects it, and runSeed falls back to the stale cache — but the error message never references the total count, making it hard to diagnose. Consider mirroring the anomalies seeder's pattern:

Fixed: changed the guard from allNormals.length === 0 to allNormals.length < MIN_ZONES (15). Now if, say, 10/22 zones succeed, the seeder throws a descriptive error mentioning the partial count and failure count, rather than silently writing a sparse result and letting validate() reject it with a generic message.